React ディレクトリ構成を思考する
指針（一旦）
hr.icon
以下の感じがいいかなぁ。なんか大袈裟やけど。
code: dir
- src/ # このディレクトリに全コード入れること
- api/ # このアプリで使う全てのAPIを叩く定義をここに記載する
- assets/ # 静的ファイル
- components/ # 機能（featuresやpages）に依存しないコンポーネント
- elements/
- layouts/
- config/ # 設定（主に環境変数など）
- features/ # 機能に依存するComponentやHook
- functions/ # 機能に依存しない関数（例外処理や、ロギング系も入れておこうか）
- hooks/ # 機能に依存しないhooks
- lib/ # 外部ライブラリを使う際にここで整理
- pages/ # ルート、pathに紐付くコンポーネント（featuresやcomponentsにあるのを組み合わせる）
- providers/ # アプリ全体に渡るprovider定義
- routes/ # ルート管理
- test/ # テストに使うための便利機能を集める （注意： テスト関数を置く場所ではない）
- types/ # アプリ全体で共通の型情報
- utils/ # functionsとややこしくはある...。まあ、「例外処理」「ロギング系」くらいしか入れてない。
ポイント
必要になった時にそのディレクトリを作ろう。
例えば、ルートのfunctions/とかは必要になる場面は少ないかも。
ただ、features内のfunctionsは作ることになるかも。
routesでルート決めて、pagesでルート毎に見た目を作る。
pagesで独自に部品コンポーネント定義とかはできる限りしてほしくない、componentsやfeaturesのものを使う。
最悪カスタムフックの定義とかは必要になる可能性はある。挙動の調整とかで。
迷い
一部api/をfeaturesの中で定義しちゃったほうがいいっていう意見がある。ベストプラクティス系で。
ただ、まだその必要性がわかってない。
いや、必要性はわかるけど、featureと1：1にならないapiとかもあって、定義箇所がバラバラになるの嫌やなと。
ここは様子見。
typesの扱いに困る。
色んな箇所でtypesを定義することになるんだけど、DRYにできるところはするかしないかみたいな判断。
これはDDDあたりの話になってくるのかな、コンテキスト違うなら別々に型定義しろってことかな。
そういう判断で、どこの型定義ファイルにこの型を置くかみたいな判断をしていくか。
基本的には、バックエンドがモデル定義の中心になってると思うねん。
だから、apiのレスポンス用に定義した型をいい感じに使っていくようにしたほうがいいかな。
思考
hr.icon
アプリの規模によらず最低限欲しいかもなディレクトリ
code: dir.sh
- src/
- api/ # APIを叩くための奴ら。
- assets/ # 静的ファイル
- components/ # 共通コンポーネント
- elements/ # 細かいの
- layouts/ # レイアウト
- config/ # 設定
- pages/ # ページ
- hooks/ # 共通hooks
- providers/ # アプリ全体に渡るcontextとprovider
- routes/ # ルート管理
- test/ # テストに使うやつ
- types/ # 型情報
- lib/ # アプリ全体で使う便利機能系（util系もここに入れよう）
んや、もっと小さくできないか....
ん〜〜〜、最悪routesやprovidersは必要ないくらい？
typesとかも最悪必要ないかなぁ
hooksも最悪必要ないか？共通hooksなんてそう出てこないのではないか
てなると以下の感じになるのかな
code: dir
src/
- api/
- assets/
- components/
- elements/
- layouts/
- config/
- pages/
- test/
- types/
- lib/
て感じか？
lib/は外部ライブラリ関連のコードを書くイメージしてる。
axiosなど。
utilsは、ロギング、エラー処理的なやつ。
あれ、でも待てよ。pagesとroutesってやってることほぼ同じやな。
routesの中にrouteていうディレクトリ作って、そこにpagesのデータを入れても良いのでは？？？
だって、routeとpageって1：1やんな。
情報収集
hr.icon
featuresは言ってしまえば、DDDのドメイン的な考え方で思っておけばOK。
featuresの役割はなんとなくいいなと思いつつ、それとは別にpagesも必要な気がしている。onigiri.w2.icon
このアプリにpagesが無い理由は、Dashboard的な感じの構成にしてるから。
つまり、サイドバーがあって、そこをクリックしながらコンテンツ内容を切り替える感じのアプリケーション。
ザ・SPAって感じのアプリ構成。
そうなんよな、SPAって本来こんな感じのイメージなんよ。pagesっていうよりかは。
だからこのアプリにもpagesが無いんだと思う。
このアプリでは、layoutやroutesでダッシュボードのレイアウトを設計して、そこにfeaturesのコンポーネントを詰め込む感じになってそう。
ここではpagesを定義してるonigiri.w2.icon
うん、これはいい感じ。必要なページをpagesで作成しつつ、そこに必要なパーツをsrc/componentsやfeaturesから取得して組み合わせてる。
いい感じだと思う。
ダッシュボード的なSPAじゃなくて、ページ遷移っぽいSPAなら、こういう構成になるのが良いんじゃない？って感じ。